NetPresenz was previously called “FTPd”. This is the same program, albeit a new version. If you have a license to FTPd, that license is automatically a license to use NetPresenz (although there is an upgrade fee if you purchased FTPd prior to Jan 1, 1996).
Documentation Part 2
Contents
Part 1
What NetPresenz Does
Features
Using NetPresenz Setup
FTP Setup
WWW and Gopher Setup
FTP Setup Details
Scripting NetPresenz Setup
Using NetPresenz
Referring to your Server
Using NetPresenz from a Un*x FTP Client
Remote Volume Mounting
Miscellaneous FTP Commands
WWW
Server Side Includes
CGIs
Java
Missing files
Gopher
Registering
Site Licensing
Part 2
Security Considerations
Avoid the Wrath of your Network Admin
Limitations
Remote Site Access Restrictions
Warranty
Fine Print
Acknowledgements
How It Works
Security Considerations
“Be afraid. Be very afraid” - The Fly
Allowing NetPresenz to run on your Mac poses huge security questions. Some of the same security questions are also posed by System 7 File Sharing. However with NetPresenz they are much worse because you’re making your Mac accessible to everyone on a world wide network. Things you definitely should do:
Disable guest logins unless you actually need them. You need guest logins enabled for anonymous FTP, and Gopher or WWW access.
If you want a few people to have access, perhaps a better idea than guest login is to give them a single account with a shared password. This is more secure than guest logins, since no matter how many people they tell the password to, it will always be less than the number of people who could log in as guests.
Disable remote mounting to guests or users. Again, most people don’t need access to volumes other than those directly on your Macintosh (That is the Entire Volume and Shared Folder volumes). You Definitely Should Not allow access to other volumes on the network if you do not control them, and you Definitely Should inform the administrators of any other servers on the network that you will be allowing access to them so that they can secure their servers as well.
Only share a small portion of your file system. That way you don’t have to worry about the rest of it. You, as the owner, can still get access to it by using the Users & Groups control panel to turn on the “Allow user to see entire disk” checkbox for your user.
Verify that the file sharing privileges are set correctly. A good start is to change everything to owned by you and only visible/modifiable by you. Then change the privileges on areas that you want to give users and guests access.
Keep your password secure! Anyone on the Internet with your username, machine address and password will likely be able to delete every file on your harddisk. This is a scary thought. You should be scared. Don’t give your password out and don’t use an obvious password. Obvious passwords include, but are not limited to, any of the following patterns (in decreasing obviousness)...
your user name.
your real name.
your initials.
your husband’s/wife’s/girlfriend’s/boyfriend’s/dog’s/frog’s/machine’s etc name.
your car licence plate, make, model, etc.
your birthday.
your student/MediCare/social security/tax file/etc number.
any of the above backwards.
any word from a dictionary (especially an electronic dictionary).
Good passwords can be found by making up nonsense words or using
letters from a common saying and by including non-alphanumeric ASCII
characters.
Invalid login attempts are logged to a log file in the Preferences folder (assuming logging is enabled). Check the log file regularly to improve your security.
If in doubt, don’t run NetPresenz. I can’t accept any liability for any problems. I have done my best to make sure it is secure. If that is not good enough, don’t use it. It’s as simple as that.
Avoid the Wrath of your Network Admin
FTP can use a lot of bandwidth and so you should check with the system administrators on your network before setting up an FTP site for anything more than personal use.
Also, since NetPresenz can make other servers on the entire AppleTalk Internet available for FTP, you should ensure that the administrators of such machines (including anyone who has File Sharing enabled on their Mac) are aware of this before you allow remote mounting.
I can’t accept any responsibility if you use this software in an irresponsible manner (in fact I won’t accept any responsibility no matter how you use this software!). As long as you disable remote mounting and don’t try to become the next Info-Mac archive, it shouldn’t be much of a problem, but check with your network administrators anyway.
Limitations
NetPresenz & NetPresenz Setup require System 7 with File Sharing turned on, MacTCP 1.1 or OpenTransport 1.1 (or later versions) and probably require the 128k ROM (or later). NetPresenz should work fine with MacTCP 2.0.6 or Open Transport.
AutoDoubler users should exclude the folders that are shared with File Sharing. Also, AutoDoubler causes uploads from the local machine to fail with an I/O Error - uploads from other machines seem to work ok, and it’s useless to upload from the same machine anyway, so this should not be a problem.
NetPresenz requires File Sharing or AppleShare which in turn requires AppleTalk. If you are on a serial network (eg SLIP or PPP), then you may not have an AppleTalk network and you may not want to waste a serial port just to turn AppleTalk on. You can get around this by using a Dummy network device which will let you have File Sharing on without any physical network connection.
or (especially if you have a Duo), try Single Talk:
</info-mac/comm/atlk/single-talk-11.hqx>
If you use Open Transport you can use the Remote Only extension which comes in the Open Transport Extras directory of the Open Transport 1.1.1 installation.
Remote Site Access Restrictions
You can limit the machines that can access your site by restricting access to certain IP ranges. Because this would be very messy to do in a sensible user interface, the only way to set these restrictions is by using ResEdit. From ResEdit, create a STR# resource (in either the NetPresenz Preferences file or NetPresenz (the former overrides the latter), give it an id in the range of 600-699, and a name ending of:
“<username> Site Restriction” where <username> is the user you are restricting.
“Owner Site Restriction” to restrict the owner.
“User Site Restriction” to restrict any unspecified user.
“Anonymous Site Restriction” to restrict anonymous logins.
“Default Site Restriction” to restrict anyone not specified above.
NetPresenz checks them in that order (for gopher restrictions, it checks Anonymous Site Restriction or Default Site Restriction). Each resource consists of a sequence of pairs, IP number, IP mask, both in dotted decimal format (eg 134.7.70.70). The remote IP is checked against the IP, with only the bits in the mask being relevant. If it matches then the user is allowed access. If it matches, but the IP string started with an exclamation mark then access is disallowed. The last match overrides previous ones, and if there are no matches then access is denied.
By default, NetPresenz has a single “Default Site Restriction” STR# resource, which contains 0.0.0.0, 0.0.0.0 so access is allowed from anywhere.
Here are some examples, first if you just wanted to restrict anonymous logins to inside 134.7, and everyone else has no restriction, then you create two STR# resources, either in NetPresenz Preferences (which is checked first) or NetPresenz, like this:
“Anonymous Site Restriction”: 134.7.0.0,255.255.0.0
You don't need to create the “Default Site Restriction”, because it already exists in NetPresenz, if you wish to override the default, either change it in NetPresenz or add a “Default Site Restriction” to NetPresenz Preferences.
Ok, and a more complicated one, say you wanted anonymous access to everywhere inside 134.7 except 134.7.70.70, user access to everywhere inside 134.7 and 130.95, user "Fred" and the owner access from everywhere, do this:
“Anonymous Site Restriction”: 134.7.0.0,255.255.0.0, !134.7.70.70,255.255.255.255
“User Site Restriction”: 134.7.0.0,255.255.0.0, 130.95.0.0,255.255.0.0
“Owner Site Restriction”: 0.0.0.0,0.0.0.0
“Fred Site Restriction”: 0.0.0.0,0.0.0.0
Note: These restrictions apply only to the control connection, not the data transfer connections, so it is still possible to use proxy-ftp to transfer files directly to a restricted machine, but the user must be connected from an allowed site.
Warranty
This program should do what I’ve described in this document. If it doesn’t, you can simply stop using it. If you pay me, and within a year find that it doesn’t do what I describe here, then you can notify me and I will refund your money and cancel your license.
Fine Print
Peter Lewis and Stairways Software Pty Ltd hereby disclaims all warranties relating to this software, whether express or implied, including without limitation any implied warranties of merchantability or fitness for a particular purpose. Peter Lewis and Stairways Software Pty Ltd will not be liable for any special, incidental, consequential, indirect or similar damages due to loss of data or any other reason, even if Peter Lewis, Stairways Software Pty Ltd, or an agent of his has been advised of the possibility of such damages. In no event shall Peter Lewis or Stairways Software Pty Ltd be liable for any damages, regardless of the form of the claim. The person using the software bears all risk as to the quality and performance of the software.
US Government:
Government End Users: If you are acquiring the Software and fonts
on behalf of any unit or agency of the United States Government, the
following provisions apply. The Government agrees:
(i) if the Software and fonts are supplied to the Department of
Defense (DoD), the Software and fonts are classified as "Commercial
Computer Software" and the Government is acquiring only "restricted rights"
in the Software, its documentation and fonts as that term is defined in
Clause 252.227-7013(c)(1) of the DFARS; and
(ii) if the Software and fonts are supplied to any unit or agency
of the United States Government other than DoD, the Government's rights in
the Software, its documentation and fonts will be as defined in Clause
52.227-19(c)(2) of the FAR or, in the case of NASA, in Clause
18-52.227-86(d) of the NASA Supplement to the FAR.
Acknowledgements
Thanks to RobT for suggesting the idea, to Quinn for demanding the use of System 7 U&G, and to Jager for figuring out how! Thanks to Quinn (again :) for the amazing icons and to Greg for colouring them in. And special thanks again to Jager and Quinn for figuring out my async problems! And, of course, thanks to Stuart for delaying the release of this program for ages by making LOTS of suggestions, finding LOTS of bugs, and by writing Bolo! Thanks also to the UCC, Todd, Steve, c.s.m.p, archie.au, ftp.apple.com, Farhad, Tom, Andr'e, Aron, Ben, David, Gregory, Guy, Igor, Jim, John, Ken, Leonard, Frederic, Pete, Peter, Richard (who won the award for the most mail messages (after Quinn)), Rob, Russell, Thede, Tom, Zep, and anyone who uses NetPresenz!
I can’t describe how important the beta testers have been in making NetPresenz what it is, without them NetPresenz would not be a shadow of what it is now. So special thanks go to all of you who made suggestions or pointed out problems. I tried to list you all, but I gave up, there are just too many. Some of you made so many suggestions I couldn't count them all. Some of you analysed the network packets to find out what was happening and explained where I was going wrong. Some decompiled my code and sent it back to me with corrections. Some made suggestions that involved tiny changes with great benefits. Some made outrageous demands which I refused to do, and others outrageous demands which I eventually did. All of these would have been missing if I was working on my own. Thanks.
Thanks also to Mike Marburger for the closing sound.
How It Works
NetPresenz listens for TCP connections on port 21. When a connection is achieved, it waits for commands to be sent to it. Commands all have a simple form, there is a 3 or 4 character command (eg, RETR for retrieve file), and some parameters (eg, filename). NetPresenz interprets these commands, carries out their actions, and replies with a one line message, the first three characters of which are a 3 digit reply that can be interpreted by the FTP client, then the rest is human readable information. The reply codes are 1yz for preliminary success (action started), 2yz for complete success (action finished successfully), 3yz for intermediate success (requires another command before any action is taken), 4yz for temporary failure (try again later), and 5yz for permanent failure (give up and go home). For more information on the formats of these commands see the various FTP related RFCs. Some commands may reply with a multiline response, in which the first line begins with a three digit response code followed by a dash “-” followed by several lines of text and terminated by a line with the same response code and a space followed by some text. This confuses some servers, you can disable this feature by starting your username or password with a dash “-”.
NetPresenz also listens to port 70 for gopher connections. It then accepts a single line specifying either a folder, file, or index, and returns the info for it. The gopher server logs in as an AppleShare guest user, so guest access must be enabled (it was either that, or NetPresenz would have to know a user password, which I wanted to avoid). The root of the gopher tree is specified by the login directory for fake user “Gopher” (it defaults to /). This root is enforced, so you can’t have aliases pointing to folders outside this area (well, you can, but it won't work very well). Aliases to files outside the area work. You can reduce this restriction with the “GopherRoot” user directory, but that will allow anyone knowledgeable in the gopher protocol to get at any file inside that root.
NetPresenz talks to the file system on the local Mac (and other servers) exclusively by using the same protocols as if it were accessing an AppleShare server (the single exception is the startup messages which are read via normal file system calls). The user logs in by giving a user name and password. This in turn is passed to the System 7 server (or AppleShare server) and an attempt is made to log in to the server. If the log in fails, an attempt is made to log in as a guest user. If either attempt succeeds, the volume is made available to the user. If the user tries to log in as either the owner or a user, they must successfully (non-anonymously) log in to at least one local volume or the whole connection is disallowed. Since all file system access is done through the AppleShare protocols, it should be virtually impossible to circumvent their protections. You should set up your system in such a way that irrespective of the privileges in NetPresenz Setup (which are not guaranteed in any way!) the user cannot do too much damage. Thus users and guests should only have write privileges to areas of your file system that you wish them to be able to trash.
